Asynchronous management of access requests to control power consumption

ABSTRACT

Systems and methods are disclosed for asynchronous management of access requests to control power consumption. In some cases, by asynchronously managing power within a system, multiple dies of a NVM can simultaneously draw current in order to match the power demand. In particular, an arbiter of the system can receive multiple requests to draw current, where each request may be associated with a different die of the NVM. In some embodiments, the arbiter can determine the servicing order using the time of arrival of the request (e.g., a first-in, first-out scheme). In other embodiments, the arbiter can simultaneously service multiple requests so long as the servicing of the multiple requests does not exceed a power budget.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.13/105,161, which is incorporated by reference herein in its entirety.

BACKGROUND OF THE DISCLOSURE

Memory devices, such as volatile memories and non-volatile memories(“NVMs”), are commonly used for mass storage. For example, consumerelectronics such as portable media players often include different typesof memory to store music, videos, and other media.

For example, a system having non-volatile memory can receive multiplerequests from a file system to access one or more dies of thenon-volatile memory. Each of these requests may be associated with aparticular current draw. Hence, during a particular period of time, thesystem may have multiple outstanding requests that need to draw currentfrom a power source.

Conventionally, a token can be circulated from die to die, and a requestmay be serviced only when a die associated with the request has beenprovided with the token. Latency problems may exist in such aconfiguration. In particular, once a particular die has passed off thetoken, the die must wait for a period of time before a requestassociated with the die can be serviced.

SUMMARY OF THE DISCLOSURE

Systems and methods are disclosed for asynchronous management of memoryto control power consumption. By asynchronously managing power within asystem, multiple dies of a NVM can be used with minimum latency andpower consumption.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects and advantages of the invention will becomemore apparent upon consideration of the following detailed description,taken in conjunction with accompanying drawings, in which like referencecharacters refer to like parts throughout, and in which:

FIG. 1 is a block diagram of an electronic device configured inaccordance with various embodiments of the invention;

FIG. 2 is a graphical view of one approach to management of powerconsumption;

FIG. 3 is a graphical view of another approach to management of powerconsumption in accordance with various embodiments of the invention;

FIG. 4 is a flowchart of an illustrative process for updating a queue ofrequests in accordance with various embodiments of the invention;

FIG. 5 is a flowchart of an illustrative process for servicing one ormore requests to access a memory in accordance with various embodimentsof the invention; and

FIG. 6 is a flowchart of an illustrative process for completing one ormore requests to access a memory in accordance with various embodimentsof the invention.

DETAILED DESCRIPTION OF THE DISCLOSURE

Systems and methods for asynchronous management of memory, includingnon-volatile memory (“NVM”), to control power consumption are provided.Asynchronous management of power consumption can reduce input/outputlatencies in a system.

In some embodiments, an arbiter of a system can receive a request from aNVM interface, where the request may be associated with a die of a NVM.The request may be an access request (e.g., a read, program, or erasecommand).

Once the request has been received, the arbiter can add the receivedrequest and associated current draw to a queue of requests. The queue ofrequests can include requests that have been received from the NVMinterface but that have not yet been serviced. After the request andassociated current draw has been added to the queue, the arbiter cansend a signal to the NVM interface, where the signal acknowledges therequest.

In order to service one or more requests in a queue of requests, thearbiter can select a request from the queue of requests. The arbiter canthen determine whether adding a current draw of the request to a currentconsumption will exceed a power budget of the system. If the arbiterdetermines that adding the current draw of the request to the currentconsumption will not exceed the power budget, the arbiter can select toservice the request by enabling the die that is associated with therequest to draw current from a power source.

In some cases, the arbiter can receive multiple requests to drawcurrent, where each request may be associated with a different die of aNVM. After receiving the multiple requests, the arbiter may determine aservicing order using one or more suitable parameters such as, forexample, the time of arrival of a request, the amount of current draw ofa request, a power budget, any other suitable parameter, and/or anycombination thereof.

In some embodiments, the arbiter can determine the servicing order usingthe time of arrival of a request (e.g., using a first-in, first-outscheme). In other embodiments, the arbiter can simultaneously servicemultiple requests so long as the servicing of the multiple requests doesnot exceed the power budget.

FIG. 1 illustrates a block diagram of electronic device 100. In someembodiments, electronic device 100 can be or can include a portablemedia player, a cellular telephone, a pocket-sized personal computer, apersonal digital assistance (“PDA”), a desktop computer, a laptopcomputer, and any other suitable type of electronic device.

Electronic device 100 can include system-on-a-chip (“SoC”) 110,non-volatile memory (“NVM”) 120, and power source 140. Non-volatilememory 120 can include multiple integrated circuit (“IC”) dies 124,which can be but is not limited to NAND flash memory based on floatinggate or charge trapping technology, NOR flash memory, erasableprogrammable read only memory (“EPROM”), electrically erasableprogrammable read only memory (“EEPROM”), Ferroelectric RAM (“FRAM”),magnetoresistive RAM (“MRAM”), Resistive RAM (“RRAM”), or anycombination thereof.

Each one of NVM dies 124 can be organized into one or more “blocks”,which can the smallest erasable unit, and further organized into“pages”, which can be the smallest unit that can be programmed or read.Memory locations (e.g., blocks or pages of blocks) from correspondingNVM dies 124 may form “super blocks”. Each memory location (e.g., pageor block) of NVM 120 can be referenced using a physical address (e.g., aphysical page address or physical block address). In some cases, NVMdies 124 can be organized for random reads and writes of bytes and/orwords, similar to SRAM.

In some embodiments, NVM 120 can include NVM controller 122 that can becoupled to any suitable number of NVM dies 124. NVM controller 122 caninclude any suitable combination of processors, microprocessors, orhardware-based components (e.g., ASICs).

NVM controller 122 may include arbiter 130, which can efficientlytransfer data between NVM 120 and NVM interface 118, and arbitrate theuse of NVM dies 124. For example, based at least in part on a powerbudget of electronic device 100, arbiter 130 can control which of NVMdies 124 can draw current during a particular period of time. As usedherein, a “power budget” can refer to a peak current capacity ofelectronic device 100.

Arbiter 130 is shown with a dashed-line box in FIG. 1 to indicate thatits function can be implemented in different locations in electronicdevice 100. For example, rather than being included in NVM controller122, arbiter 130 can instead be implemented in SoC 110 (e.g., in NVMinterface 118). As another example, arbiter 130 can be implemented in acontroller of a target device of electronic device 100 (e.g., a flashmemory drive controller or SD card controller).

Arbiter 130 can receive one or more requests from NVM interface 118 toaccess NVM dies 124, where each request can be associated with aparticular current draw. In response to receiving the requests, arbiter130 can asynchronously enable the dies associated with the one or morerequests to draw current from power source 140. The functionalities ofan arbiter will be described in greater detail in connection with FIGS.3-6.

SoC 110 can include SoC control circuitry 112, memory 114, and NVMinterface 118. SoC control circuitry 112 can control the generaloperations and functions of SoC 110 and the other components of SoC 110or device 100. For example, responsive to user inputs and/or theinstructions of an application or operating system, SoC controlcircuitry 112 can issue read or write requests to NVM interface 118 toobtain data from or store data in NVM 120. For clarity, data that SoCcontrol circuitry 112 may request for storage or retrieval may bereferred to as “user data”, even though the data may not be directlyassociated with a user or user application. Rather, the user data can beany suitable sequence of digital information generated or obtained bySoC control circuitry 112 (e.g., via an application or operatingsystem).

SoC control circuitry 112 can include any combination of hardware,software, and firmware, and any components, circuitry, or logicoperative to drive the functionality of electronic device 100. Forexample, SoC control circuitry 112 can include one or more processorsthat operate under the control of software/firmware stored in NVM 120 ormemory 114.

Memory 114 can include any suitable type of volatile memory, such asrandom access memory (“RAM”) (e.g., static RAM (“SRAM”), dynamic randomaccess memory (“DRAM”), synchronous dynamic random access memory(“SDRAM”), double-data-rate (“DDR”) RAM), cache memory, read-only memory(“ROM”), or any combination thereof. Memory 114 can include a datasource that can temporarily store user data for programming into orreading from non-volatile memory 120. In some embodiments, memory 114may act as the main memory for any processors implemented as part of SoCcontrol circuitry 112.

NVM interface 118 may include any suitable combination of hardware,software, and/or firmware configured to act as an interface or driverbetween SoC control circuitry 112 and NVM 120. For any software modulesincluded in NVM interface 118, corresponding program code may be storedin NVM 120 or memory 114.

NVM interface 118 can perform a variety of functions that allow SoCcontrol circuitry 112 to access NVM 120 and to manage the memorylocations (e.g., pages, blocks, super blocks, integrated circuits) ofNVM 120 and the data stored therein (e.g., user data). For example, NVMinterface 118 can interpret the read or write requests from SoC controlcircuitry 112, perform wear leveling, and generate read and programinstructions compatible with the bus protocol of NVM 120.

While NVM interface 118 and SoC control circuitry 112 are shown asseparate modules, this is intended only to simplify the description ofthe embodiments of the invention. It should be understood that thesemodules may share hardware components, software components, or both. Forexample, SoC control circuitry 112 may execute a software-based memorydriver for NVM interface 118.

Power source 140 can include any suitable electronic power device orsystem capable of supplying power to the components of electronic device100. In some embodiments, power source 140 can be an internal powersource, such as a battery of electronic device 100. In otherembodiments, power source 140 can be an external power source, such as alaptop computer, a power supply, or a docking station. Thus, powersource 140 is shown with a dashed-line box in FIG. 1 to indicate thatits function can be implemented in different locations (e.g., as astand-alone module in electronic device 100 or as a module external toelectronic device 100).

In some embodiments, electronic device 100 can include a target device,such as a flash memory drive or SD card, that includes NVM 120 and someor all portions of NVM interface 118. In these embodiments, SoC 110 orSoC control circuitry 112 may act as the host controller for the targetdevice. For example, as the host controller, SoC 110 can issue read andwrite requests to the target device.

Referring now to FIG. 2, a graphical view of a round-robin approach tomanaging power consumption is shown. Dies 0-5 can be the same as orsubstantially similar to NVM dies 124 of FIG. 1. Persons skilled in theart will appreciate that a system can include any suitable number ofdies. For the sake of simplicity, however, only six dies are shown inFIG. 2.

Using a round-robin approach, token 202 may be circulated to each ofdies 0-5. Once a die has been provided with token 202, it can drawcurrent from a power source (e.g., power source 140 of FIG. 1). Once aparticular die has finished drawing current, it can pass token 202 to adifferent die.

For example, as shown in FIG. 2, at time t₀, die 0 has possession oftoken 202. As a result, die 0 can draw current from the power source.Once die 0 has finished drawing current from the power source, it canpass token 202 to die 1 at time t₁. Consequently, die 1 can draw currentfrom the power source, and, at time t₂, die 1 can pass token 202 to die2. This process can continue to all of the remaining dies until die 5has possession of token 202 at time t₅. Once die 5 has finished drawingcurrent from the power source at time t₆, token 202 can be passed backto die 0.

In such a configuration, a latency problem exists because once a die hasdrawn power, the die needs to wait for a period of time (e.g., an entireround robin clock cycle) before it can draw power again. For example,after drawing current at time t₀, die 0 must wait until time t₆ beforeit regains possession of token 202 and is able to draw current from thepower source. Consequently, this approach to managing power consumptioncan be used for a system that has sequential write operations, wheredies can be enabled to draw current in a sequential fashion. However, inthe case of a system with asynchronous (e.g., random) write operations,the system may need to enable dies to draw current in an asynchronousfashion in order to match the power demand.

Referring now to FIG. 3, a graphical view of asynchronous management ofpower consumption is shown. Arbiter 302 can asynchronously manage powerconsumption of a system such that a particular die of NVM does not needto wait for a round robin clock cycle to complete before drawing currentagain. Arbiter 302 can be the same as or substantially similar toarbiter 130 (FIG. 1). In addition, dies 0-5 can the same as orsubstantially similar to NVM dies 124 of FIG. 1 or dies 0-5 of FIG. 2.Persons skilled in the art will appreciate that a system can include anysuitable number of dies. For the sake of simplicity, however, only sixdies are shown in FIG. 3. Persons skilled in the art will alsoappreciate that the asynchronous power management approach discussedbelow can be used in any other suitable power management contexts suchas, for example, in volatile memories (e.g., SRAMs), co-processors, orany other suitable system components.

Arbiter 302 can receive multiple requests to draw current from a NVMinterface (e.g., NVM interface 118 of FIG. 1), where each request may beassociated with a different die of a NVM (e.g., one of NVM dies 124 ofFIG. 1, dies 0-5 of FIG. 2, or dies 0-5 of FIG. 3). In particular, eachrequest of the received requests can be an access request. As usedherein, an access request can be a request to perform an operation(e.g., a read, program, or erase operation) on one or more dies of aNVM.

For example, as shown in FIG. 3, arbiter 302 may receive requestsassociated with die 0 at time t₀, die 2 at time t₁, die 1 at time t₂,die 1 at time t₃, die 4 at time t₄, die 5 at time t₅, and die 3 at timet₆. In response to receiving the multiple requests, arbiter 302 can addthe multiple requests and associated current draws to a queue ofrequests 304. In some embodiments, queue of requests 304 can includerequests that have been received from the NVM interface but that havenot yet been serviced. In addition, in some cases, arbiter 302 can sendmultiple signals to the NVM interface, where each signal acknowledgeseach of requests 306-318.

At a later time, arbiter 302 can service one or more requests from queueof requests 304, where the servicing of the one or more requests doesnot exceed the power budget. Arbiter 302 can determine a servicing orderfor one or more of the requests based on any suitable suitableparameter(s). For example, the parameters can include the time ofarrival of a request, the amount of current draw of a request, a powerbudget, any other suitable parameter, and/or any combination thereof.

For example, arbiter 302 can determine the servicing order using thetime of arrival of a request. In one implementation, arbiter 302 candetermine the servicing order based on a first-in, first-out scheme. Forinstance, arbiter 302 can service each of the requests 306-318 based onthe time of arrival of each request. As a result, request 306 will beserviced first, followed by request 308, request 310, and so forth.

In other embodiments, arbiter 302 can simultaneously service multiplerequests so long as the servicing of the multiple requests does notexceed the power budget. That is, arbiter 302 can limit the number ofdies that can simultaneously draw current from the power source suchthat the power budget is not exceeded.

For example, in some cases, arbiter 302 can determine the servicingorder of multiple requests based on a best-fit scheme. For example,arbiter 302 can select to service a maximum number of requests, wherethe total amount of current that needs to be drawn of the selectedrequests is less than or equal to the power budget. As a result, therequests that are selected for servicing can be based at least in parton the power budget.

In the example shown in FIG. 3, for instance, arbiter 302 may determinethat requests 306 and 308 cannot be serviced simultaneously withoutexceeding the power budget. That is, provided that arbiter 302 hasstarted servicing request 306, arbiter 302 can determine that adding thecurrent draw (e.g., C₂) of request 308 to the current consumption willexceed the power budget. As a result, arbiter 302 can delay servicingrequest 308 until the current consumption has decreased.

In contrast, arbiter 302 may determine that requests 306 and 310 can beserviced simultaneously without exceeding the power budget. That is,provided arbiter 302 has started servicing request 306, arbiter 302 candetermine that adding the current draw (e.g., C₃) of request 310 to thecurrent consumption will not exceed the power budget. As a result,arbiter 302 can service requests 306 and 310 at the same time (e.g., byenabling dies 0 and 1 to simultaneously draw current from the powersource).

After a period of time, arbiter 302 can determine that the servicing ofrequest 306 has finished. Arbiter 302 may then remove request 306 fromqueue of requests 304. Arbiter 302 can then begin to service request 308in combination with request 310.

As another example, if there are three open requests (e.g., openrequests 314, 316, and 318 in queue of requests 304), arbiter 302 canselect to service a maximum number of requests (e.g., requests 314 and318), where the total amount of current that needs to be drawn is stillless than or equal to the power budget.

Accordingly, because multiple requests (e.g., requests associated withone or more dies of a NVM) can be serviced without having to wait for around robin cycle to complete, the latency for servicing power requestsand the corresponding input/output latency may be reduced.

Turning now to FIGS. 4-6, flowcharts of illustrative processes are shownin accordance with various embodiments of the invention. These processesmay be executed by one or more components of a system (e.g., electronicdevice 100 of FIG. 1). For example, at least some of the steps in theprocesses of FIGS. 4-6 may be performed by an arbiter (e.g., arbiter 130of FIG. 1 or arbiter 302 of FIG. 3). In addition, persons skilled in theart will appreciate that at least some of the steps may be performed bya NVM interface (e.g., NVM interface 118 of FIG. 1), SoC controlcircuitry (e.g., SoC control circuitry 112 of FIG. 1), and/or NVMcontroller (e.g., NVM controller 122 of FIG. 1).

Turning first to FIG. 4, process 400 is shown for updating a queue ofrequests. Process 400 may begin at step 402, and, at step 404, thearbiter can determine whether a request has been received from a NVMinterface (e.g., NVM interface 118 of FIG. 1). If, at step 404, thearbiter determines that a request has not been received, process 400 canreturn to step 402, where the arbiter can continue to wait for requests.

If, at step 404, the arbiter instead determines that a request has beenreceived, process 400 can move to step 406. For example, referring backto FIG. 3, at time t₀, arbiter 302 may receive a request to draw currentfrom the NVM interface, where the request may be associated with die 0.

At step 406, the arbiter can add the request and associated current drawto a queue of requests. For example, the arbiter can add request 306(FIG. 3) and associated current draw C₁ to queue of requests 304 (FIG.3).

Continuing to step 408, the arbiter can send a signal to the NVMinterface, where the signal acknowledges the request. Then, at step 410,the arbiter can sort the queue of requests. For example, referring backto FIG. 3, arbiter 302 can sort requests 306-318 based on theirassociated current draw (e.g., C₁-C₇). In some cases, arbiter 302 cansort requests 306-308 from minimum current draw to maximum current draw.This way, when arbiter 302 is ready to service one or more requests fromqueue 304, arbiter 302 can select to service the first request in queue304, which consequently can also be the request requiring the leastamount of power. After sorting the queue, process 400 may return to step404, where the arbiter can continue to receive additional requests fromthe NVM interface.

Turning now to FIG. 5, process 500 is shown for servicing one or morerequests to access a NVM. Process 500 may start at step 502, and, atstep 504, an arbiter can receive a power budget. For example, thearbiter can receive a power budget from an NVM interface (e.g., NVMinterface 118 of FIG. 1) or from a NVM controller (e.g., NVM controller122 of FIG. 1).

Continuing to step 506, the arbiter can determine if a queue of requests(e.g., queue of requests 304 of FIG. 3) is empty. If, at step 506, thearbiter determines that the queue of requests is empty, step 500 mayreturn back to step 506, where the arbiter can continue to wait for oneor more requests to accumulate in the queue.

If, at step 506, the arbiter instead determines that the queue ofrequests is not empty, process 500 may move to step 508. At step 508,the arbiter can select a request from the queue of requests. Forexample, referring back to FIG. 3, arbiter 302 can select request 306from queue of requests 304.

Then, at step 510, the arbiter can determine whether adding a currentdraw of the request to a current consumption will exceed the powerbudget. For example, arbiter 302 (FIG. 3) can determine if adding thecurrent draw (e.g., C₁) of request 306 to a current consumption willexceed the power budget. If, at step 510, the arbiter determines thatadding the current draw of the request to the current consumption willexceed the power budget, process 500 may return to step 506. The arbitercan thus delay servicing the request until the current consumption hasdecreased.

If, at step 510, the arbiter instead determines that adding the currentdraw of the request to the current consumption will not exceed the powerbudget, process 500 may move to step 512. At step 512, the arbiter canselect to service the request. For example, arbiter 302 (FIG. 3) canservice request 306 (FIG. 3) by enabling die 0 to draw current from apower source (e.g., power source 140 of FIG. 1). In some cases, thearbiter may service the request along with one or more other requests.

Continuing to step 514, the arbiter can update the current consumptionwith the current draw of the request. For example, after servicingrequest 306, arbiter 302 can update the current consumption by addingthe current draw of request 306 (e.g., C₁) to the current consumption.Process 500 may then return to step 506, where additional requests canbe serviced.

Turning now to FIG. 6, a flowchart of illustrative process 600 is shownfor completing one or more requests to access a non-volatile memory.Process 600 may begin at step 602, and, at step 604, an arbiter candetermine whether a request has completed. If, at step 604, the arbiterdetermines that a request has not completed, process 600 may return tostep 604, where the arbiter can continue to wait for the completion ofone or more requests.

If, at step 604, the arbiter instead determines that a request hascompleted, process 600 may move to step 606. For example, referring backto FIG. 3, arbiter 302 can determine that request 306 has completed.

At step 606, the arbiter can update a current consumption with a currentdraw of the completed request. For example, arbiter 302 (FIG. 3) canupdate the current consumption by subtracting the current draw of thecompleted request (e.g., C₁) from the current consumption. Afterupdating the current consumption, process 600 may move to step 608.

At step 608, the arbiter can remove the completed request from a queueof requests. For example, arbiter 302 (FIG. 3) can remove completedrequest 306 (FIG. 3) from queue of requests 304 (FIG. 3). After removingthe completed request, process 600 may return to step 604, where thearbiter can continue to wait for additional requests to complete.

It should be understood that processes 400, 500, and 600 of FIGS. 4-6are merely illustrative. Any of the steps may be removed, modified, orcombined, and any additional steps may be added, without departing fromthe scope of the invention.

The described embodiments of the invention are presented for the purposeof illustration and not of limitation.

What is claimed is:
 1. A system comprising: a memory interface; anon-volatile memory (“NVM”) comprising a plurality of NVM dies; and anarbiter operative to: receive a power budget of the system; receive aplurality of requests to draw current from the memory interface, whereineach request of the plurality of requests is associated with a die ofthe plurality of dies; and select to simultaneously service at least asubset of the plurality of requests, wherein the at least the subset ofthe plurality of requests is selected based at least in part on thepower budget.
 2. The system of claim 1, wherein each request of theplurality of requests is an access request.
 3. The system of claim 1,wherein the power budget is a peak current capacity of the system. 4.The system of claim 1, wherein the arbiter is operative to: receive anadditional request to draw current from a die; determine if adding anassociated current draw of the additional request to current consumptionwill exceed the power budget; and in response to determining that addingthe current draw of the additional request to the current consumptionwill not exceed the power budget, select to service the additionalrequest along with the at least the subset of the plurality of requests.5. The system of claim 1, wherein in response to determining that addingthe current drawn of the additional request to the current consumptionwill exceed the power budget, the arbiter is operative to delay theservicing of the additional request.